first draft for multiple user models feature by ebarault · Pull Request #297 · loopbackio/loopback.io

ebarault · 2017-03-01T01:36:24Z

This is the PR for the documentation related to the feature introduced in strongloop/loopback#2971.

@crandmck, @beeman, @bajtos could you please take a look at this first draft?

I also performed a quick review of the Authentication, Authorization and Permissions section, with a few modifications. I will come back to this section later on in another PR, there are consistency issues to me, for example i don't quite figure out why this sub-section is included in the reviewed section.

bajtos · 2017-03-01T12:20:24Z

+module.exports = function enableAuthentication(server) {
+  server.enableAuth();
+};
+```


This is usually not enough, one has to attach all authentication models (ACL, Role, etc.) to a datasource. In our project templates, this is done by listing these models in server/model-config.json. For users adding authentication to an empty-server project, I would recommend to let enableAuth to auto-attach any required models, so that server/model-config.json changes are not required.

server.enableAuth({ dataSource: 'db' });

@bajtos : i updated the doc to let the users know about this feature anyhow

bajtos · 2017-03-01T12:21:25Z

+
+{% include note.html content="
+Usually you don't need any extra configuration regarding built-in models `Role`, `RoleMapping`, and `ACL` which you can use without any customization. Just make sure they are declared in the `model-config.json` configuration file.
+" %}


Ah, I guess this invalidates my previous https://github.com/strongloop/loopback.io/pull/297/files#r103671404

took care of merging

bajtos · 2017-03-01T12:22:13Z

+
+#### Access Control with a single user model
+
+In the case your application leverages only one type of user extending the built-in `User` model (which should the case in a majority of configurations), you barely have no further configuration to do.


which should be the case (add be)

bajtos · 2017-03-01T12:24:40Z

+
+In order to allow the Loopback access control system to work with several models extending the built-in `User` model. The relations between the `users` models and the `AccessToken` should be modified to allow a single `AccessToken` model to host access tokens for multiple types of users while at the same time allowing each `user` models instances to be linked to their related access tokens in a non ambiguous way.  
+
+This is achieved by changing the **hasMany** relation from `User` to `AccessToken` and the **belongsTo** relation from `AccessToken` to `User` by their [polymorphic](Polymorphic-relations) equivalents, in which the `principalType` property is used as a **_discriminator_** to resolve which of the potential `user` model instance an 'accessToken' instance belongs to.


[polymorphic](Polymorphic-relations)

I think this link won't work, I think the URL should include .html extension.

Oddly enough, links do work either with or without the .html ext.

yes it works locally

bajtos · 2017-03-01T12:32:33Z

+...
+app.use(loopback.token({
+  model: app.models.customAccessToken
+}));


The idiomatic way is to configure middleware in server/middleware.json.

See https://github.com/strongloop/loopback-workspace/blob/fc4f761ed7b635cf18e091b6ad111c31c78880a9/templates/projects/empty-server/files/server/middleware.json#L34

{ "auth": { "loopback#token": { "params": { "model": "customAccessToken" } } } }

(I typed the example from my head, may not work out of the box.)

@bajtos I updated as per your snippet. I'd appreciate if you can link me to the exact reference, or assert this one is good

I think this doc page is the most relevant: https://docs.strongloop.com/display/public/LB/Defining+middleware

The new content showing loopback#token configuration looks good to me.

bajtos · 2017-03-01T12:35:41Z

 You must create your own custom model (named something other than \"User,\" for example \"Customer\" or \"Client\") that [extends the built-in User model](Extending-built-in-models.html) rather than use the built-in User model directly.  The built-in User model provides a great deal of commonly-used functionality that you can use via your custom model.

-LoopBack does not support multiple models based on the User model in a single application. That is, you cannot have more than one model derived from the built-in User model in a single app.
+Since version 3, Loopback supports multiple models based on the User model in a single application. See [this section](...) on how to configure the application accordingly.


[this section](...)

Looks like a forgotten to-do :)

bajtos · 2017-03-01T12:37:23Z

Great stuff, thank you @ebarault for this contribution!

I reviewed the content, the information looks mostly correct to me, see the few comments above.

@crandmck I'll leave the text formatting and grammar conventions for you to review.

beeman · 2017-03-01T15:26:17Z

Looks good! I will give this a test later this week to see if I can get it up and running.

ebarault · 2017-03-01T18:04:20Z

@crandmck, @bajtos : I just finished reviewing @bajtos comments

crandmck · 2017-03-01T18:15:16Z

Thanks @ebarault I'd like a number of formatting/style/wording changes. Shall I just go ahead and make changes of this nature directly in the branch, rather than comment and ask you to edit?

ebarault · 2017-03-01T18:37:18Z

@crandmck : yes sure go ahead, this will be way more efficient this way. Let me know when you need a review.

crandmck · 2017-03-02T06:47:20Z

OK, I made a pass.

There is a lot here. Well done, @ebarault ! Please review my edits. I think it's mostly wording and formatting. There's enough information of a fairly specialized nature that this might ultimately deserve its own article, apart form the main "Authentication, authorization, and permissions." But that can always come later.

@bajtos I still think it needs a bit of work, but if you want to land it, I'm fine with just iterating on the published version.

One thing I noticed--really orthogonal to the rest of the PR, but still--"Authentication, authorization, and permissions" uses disableRemoteMethod(.., isStatic) instead of disableMethodByName([prototype.]...)per 3.0 RNs. IIUC, then this should change--either in this PR or we should log an issue.

ebarault · 2017-03-02T09:16:53Z

@crandmck : thanks for the review. I'm good with your changes. 👍

There are a number of things that should be reviewed in the Auth... section, other PRs will be required. @bajtos i let you decide whether you'd like to include the changes regarding disableRemoteMethod in this one or not.

bajtos · 2017-03-02T14:50:04Z

One thing I noticed--really orthogonal to the rest of the PR, but still--"Authentication, authorization, and permissions" uses disableRemoteMethod(.., isStatic) instead of disableMethodByName([prototype.]...)per 3.0 RNs. IIUC, then this should change--either in this PR or we should log an issue.

Oh, of course, please use disableRemoteMethodByName. I was typing the comments from memory and I am not used to the new API yet.

ebarault · 2017-03-02T14:52:02Z

@bajtos : it's from the original text, not from your comments

bajtos · 2017-03-02T14:53:35Z

 You must create your own custom model (named something other than \"User,\" for example \"Customer\" or \"Client\") that [extends the built-in User model](Extending-built-in-models.html) rather than use the built-in User model directly.  The built-in User model provides a great deal of commonly-used functionality that you can use via your custom model.

-LoopBack does not support multiple models based on the User model in a single application. That is, you cannot have more than one model derived from the built-in User model in a single app.
+Since version 3, Loopback supports multiple models based on the User model in a single application. See [this section](Authentication-authorization-and-permissions.html#access-control-with-multiple-user-models) on how to configure the application accordingly.


Should we spell out the specific LoopBack version where this feature was added?

- Since version 3, Loopback ... + Since version 3.3.0, Loopback ...

Also I think the correct spelling is LoopBack, not Loopback?

bajtos · 2017-03-02T14:55:57Z

Let's keep disableRemoteMethod -> disableRemoteMethodByName out of scope of this pull request please, so that it can be landed sooner.

bajtos

The changes LGTM. I left one minor comment, it can be ignored or applied in a follow-up pull request.

crandmck · 2017-03-02T20:11:24Z

I'll fix disableRemoteMethod -> disableRemoteMethodByName separately.

crandmck · 2017-03-02T21:10:51Z

I made the last small changes @bajtos suggested. I'll merge this, and we can continue to improve it. As noted previously, at some point I may open another PR to move this into a separate article.

crandmck · 2017-03-02T21:11:19Z

Thanks again @ebarault! This is a great contribution.

beeman · 2017-03-03T05:02:37Z

Great work @ebarault - I just implemented this in an example project and it works as expected: https://github.com/beeman/loopback-example-multiple-user-models

I might add some ACL's and a simple UI to demo the functionality a bit more.

Edit: that was a bit too fast. It seems that adding this line (https://github.com/beeman/loopback-example-multiple-user-models/blob/master/server/middleware.json#L37) that's noted in the docs causes an error message:

500 loopback.token() middleware requires a AccessToken model

Is there something wrong in the way I implemented it?

bajtos · 2017-03-03T09:12:28Z

👏 thank you all! 👏

ebarault · 2017-03-03T10:44:12Z

@beeman: thanks for providing this example 👍 .
I tested and I can confirm your setup is correct and there's a bug in the way the token middleware handles the auth.token config params. I'm opening a new PR to solve it. In the meantime you can continue testing by specifying the accessToken model within server.js or in a boot script.

cc: @bajtos

first draft for multiple user models feature

765035f

crandmck added the review label Mar 1, 2017

bajtos reviewed Mar 1, 2017

View reviewed changes

bajtos requested a review from crandmck March 1, 2017 12:36

revision following @bajtos review

f2b63fd

Editing, rewording, formatting, etc

69edc98

bajtos reviewed Mar 2, 2017

View reviewed changes

bajtos approved these changes Mar 2, 2017

View reviewed changes

Final edits

32d6cb1

crandmck merged commit fbcda78 into gh-pages Mar 2, 2017

crandmck removed the review label Mar 2, 2017

crandmck deleted the multiple-user-based-models branch March 2, 2017 22:10

crandmck mentioned this pull request Mar 2, 2017

Update use of disableMethodByName #302

Closed

bajtos mentioned this pull request Mar 3, 2017

Improve auth-setup instructions #304

Merged

ebarault mentioned this pull request Mar 3, 2017

fix custom token model in token middleware strongloop/loopback#3245

Merged

2 tasks

bajtos mentioned this pull request Mar 9, 2017

Add docs for creating custom AccessToken model #200

Closed


		#### Access Control with a single user model

		In the case your application leverages only one type of user extending the built-in `User` model (which should the case in a majority of configurations), you barely have no further configuration to do.


		In order to allow the Loopback access control system to work with several models extending the built-in `User` model. The relations between the `users` models and the `AccessToken` should be modified to allow a single `AccessToken` model to host access tokens for multiple types of users while at the same time allowing each `user` models instances to be linked to their related access tokens in a non ambiguous way.

		This is achieved by changing the hasMany relation from `User` to `AccessToken` and the belongsTo relation from `AccessToken` to `User` by their [polymorphic](Polymorphic-relations) equivalents, in which the `principalType` property is used as a _discriminator_ to resolve which of the potential `user` model instance an 'accessToken' instance belongs to.

Uh oh!

Conversation

ebarault commented Mar 1, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ebarault Mar 1, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bajtos Mar 1, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bajtos Mar 1, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bajtos commented Mar 1, 2017

Uh oh!

beeman commented Mar 1, 2017

Uh oh!

ebarault commented Mar 1, 2017

Uh oh!

crandmck commented Mar 1, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ebarault commented Mar 1, 2017

Uh oh!

crandmck commented Mar 2, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ebarault commented Mar 2, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bajtos commented Mar 2, 2017

Uh oh!

ebarault commented Mar 2, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bajtos commented Mar 2, 2017

Uh oh!

bajtos left a comment

Choose a reason for hiding this comment

Uh oh!

crandmck commented Mar 2, 2017

Uh oh!

crandmck commented Mar 2, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

crandmck commented Mar 2, 2017

Uh oh!

beeman commented Mar 3, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bajtos commented Mar 3, 2017

Uh oh!

ebarault commented Mar 3, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

ebarault Mar 1, 2017 •

edited

Loading

bajtos Mar 1, 2017 •

edited

Loading

bajtos Mar 1, 2017 •

edited

Loading

crandmck commented Mar 1, 2017 •

edited

Loading

crandmck commented Mar 2, 2017 •

edited

Loading

ebarault commented Mar 2, 2017 •

edited

Loading

crandmck commented Mar 2, 2017 •

edited

Loading

beeman commented Mar 3, 2017 •

edited

Loading

ebarault commented Mar 3, 2017 •

edited

Loading